1. Field of the Invention
The present invention relates to an information processing system including a client capable of receiving and reproducing content from a media server and a collecting server for receiving content management information on the content from the media server and managing the content management information, an information processing method, a computer readable medium, and a collecting server applied to the system.
2. Description of the Related Art
A DLNA (Digital Living Network Alliance) guideline is known as a technical guideline for interconnecting digital AV devices or personal computers in a home network environment. The DLNA guideline defines conditions for connection between a server providing content and a client reproducing the content. Devices conforming to this guideline can be interconnected to share contents by merely connecting a line to the devices without making any special settings.
The DLNA guideline specifies the use of UPnP (Universal Plug and Play) as a protocol for realizing alliance between devices on a network. Contents and content management information are exchanged between a client and a server on the basis of a UPnP AV specification. A user calls up a CDS (Content Directory Service) within the server from a UPnP control point using a Browse command or a Search command to obtain a list of content management information. Then, the user can obtain a desired content by accessing the URL (Uniform Resource Locator) of a location where the content is stored, the URL being included in the list of content management information.
FIG. 14 shows a state in which a DLNA client and a DLNA server (media server) are connected to each other via a network 2 such as a home LAN (Local Area Network) or the like. The DLNA client 10 includes a notebook personal computer 10a (a personal computer will hereinafter be referred to as a PC) and a television receiver 10c. The DLNA client 10 is connected via a network media receiver 15 to a notebook PC 20a, a desktop PC 20b, and a DVD (Digital Versatile Disc) recorder 20c as the DLNA server 20. FIG. 14 shows the notebook PC 20a having a photograph P1, video V1, and music M1 recorded thereon, the desktop PC 20b having a photograph P2, music M2, and video V2 recorded thereon, and the DVD recorder 20c having video V3 recorded thereon.
Because the DLNA client 10 and the DLNA server are connected to each other by a connection system conforming to the DLNA guideline, each of the devices of the DLNA client 10 can read and reproduce the contents such as the photographs, the music, and the video recorded on each of the devices of the DLNA server 20.
When the photograph P2 stored in the DLNA server 20 is to be viewed on the personal computer 10a of the DLNA client 10, for example, it suffices to access the desktop PC 20b storing the photograph P2. In this case, however, the DLNA client 10 side needs to determine which device stores the photograph P2 in advance. Thus, especially when various kinds of DLNA servers 20 store a large amount of contents, for example, it takes time and trouble to find the content.
A known method for solving this problem uses a collecting server to collectively manage content management information in each DLNA server within a house. An example of a system configuration with a collecting server is shown in FIG. 15. In the configuration shown in FIG. 15, the collecting server 30 collectively manages metadata (attribute information) of contents recorded on each device of a DLNA server 20.
In the example shown in FIG. 15, the collecting server 30 classifies contents by content type. The collecting server 30 displays video V1 recorded on a notebook PC 20a, video V2 on a desktop PC 20b, and video V3 on a DVD recorder 20c in a list under a classification of “video”. Similarly, the collecting server 30 displays a photograph P1 recorded on the notebook PC 20a and a photograph P2 recorded on the desktop PC 20b in a list under a classification of “photograph”. The collecting server 30 displays music M1 recorded on the notebook PC 20a and music M2 recorded on the desktop PC 20b in a list under a classification of “music”.
Thus, the collecting server 30 has a function of reclassifying information on recorded contents scattered across the respective devices of the DLNA server 20 by data type, artist or the like and showing the information in a list. Each of the devices of the DLNA client 10 can therefore readily search for a desired content by merely accessing the collecting server 30.
In addition to the above method, various methods are adopted to improve efficiency of content search. For example, Japanese Patent Laid-Open No. 2006-262214 (hereinafter referred to as Patent Document 1) discloses a method of automatically classifying images using metadata of the images when capturing the images from a digital camera into a PC.
As is also described in Patent Document 1, metadata of a still image taken by a digital camera, a portable telephone terminal or the like, in particular, is often only a photographing date and a title automatically given to the still image by the device. FIG. 16 shows a list of still images displayed on the collecting server 30. A screen shown in FIG. 16 displays thumbnails of the images on a left side of the screen, titles of the images such as DSC0005.JPG and the like next to the thumbnails, and photographing dates and times such as 2005/9/3 6:40 PM and the like.
However, it may be difficult to retrieve a desired image with only information as shown in FIG. 16 as a key. This is because photographing dates and times, the titles of images and the like are often classifications meaningless to the user.
Some types of DLNA clients 10 show a content hierarchical structure referred to as CDS (Container Directory Service) within the DLNA server 20 as it is on a menu screen operated by the user. CDS is a structure as shown in FIG. 17, for example, in which structure folders referred to as containers are connected to each other in a hierarchy. Some containers exist singly as containers, and some containers include real files of contents referred to as items. Incidentally, containers and items are both also referred to generically as objects.
In the example shown in FIG. 17, a container C1 named “RECORDED VIDEO” and a container C2 named “ALBUM LIST” are under a root container C0. A container C3 named “ALBUM 1” and a container C4 named “ALBUM 2” are connected under the container C2. Further, a container C5 named “EXTRAS” is connected to the container C3. The container C1 stores items It1 and It2 as video contents, the container C3 stores items It3, It4, and It5 as photographic contents, and the container C4 stores an item It6 as photographic content. That is, CDS shows folder names and a hierarchy created by a user as they are stored, and folder names in CDS are often meaningful to the user.
When such a hierarchy is displayed on a menu screen, the user can reach a desired photograph by tracing the hierarchy. However, the user often needs to move between layers many times before reaching the desired photograph, and thus it cannot be said that operability is good.
It is possible that CDS has metadata other than photographing dates and titles. When such metadata can be added to search conditions, search efficiency should be improved. FIG. 18A shows five kinds of essential metadata. FIG. 18B shows metadata that can be added arbitrarily.
The essential metadata includes @id as a unique ID assigned to each content, @parentID as the ID of content one layer above the content, @restricted indicating whether the content is changeable, dc:title indicating a title, and upnp:class indicating the type of the content. The metadata that can be added arbitrarily includes, for example, dc:date indicating date and time information, dc:description indicating an outline, upnp:artist indicating artist information, upnp:album indicating album information, upnp:genre indicating genre information, and res as the URL of a destination for obtaining content data.
However, while items that seem to be useable as content search keys can be added as arbitrarily addable metadata, the added items cannot be used as search items unless the meanings of the items are shared with the DLNA client 10. However, there is no common framework for DLNA for sharing such information. It can therefore be said that sharing metadata added as extension information between various devices forming the DLNA client 10 and the DLNA server 20 is impossible in the present situation.